約 4,400,016 件
https://w.atwiki.jp/puchi-sensha/
このwikiはGameloftが提供するios android専用アプリの非公式wikiです。 ※当wikiは非公式の攻略wikiです。情報の妥当性や正確性について保証するものではなく、一切の責任を負いかねます。 ※当wikiを利用することによって生じるいかなる損害も当サイトでは補償致しません。 ※ご利用につきましては自己責任となりますのでご注意ください。 ※また、当wikiおよびwiki管理人は○○運営様とは一切関係がありません。wiki管理人にエラーなどについて問い合わせないようお願いします。 ゲームに関する問い合わせに関してはこちらから(ゲームの開発元の問い合わせURLを編集してください。)
https://w.atwiki.jp/melodroid/pages/17.html
Armadillo-500 FX用開発環境構築 概略 Armadillo-500 FX上で動作するAndroidのビルド環境構築について記載する。 記載、および、動作確認には、cupcakeバージョンを対象としている。 バージョンによっては、不要な手順もある。 目次 Armadillo-500 FXについて 環境構築目標 ファイル取得 ファイル配置 カーネル修正 ユーザ空間修正 追加ファイル パス設定 ビルド方法 ビルドスクリプト ビルド生成物 未解決問題 検証中 Armadillo-500 FXについて Armadillo-500fxは、組込み向けの開発キットになる。 言い方を変えると、「高いおもちゃ」ということ。 仕様等の詳細は、公式となるAtmark Technoの紹介ページを見てください。 環境構築目標 Armadillo-500fx用の環境を作る上での目標をまとめておく。 テーマは、「手軽に、かっこよく」ってことで。 以下に、具体的な目的をまとめておく。 コマンドひとつで、カーネル+ユーザ層がビルドできるようにする eeepc701用のビルドで採用されているように、vendor配下を作ってみる 生成物を焼きやすい形にまとめるようにする いろいろ手順が簡単になるようにする ファイル取得 環境を作成する上で元となるソースの取得方法について記載する。 取得するソースは、2種類に分かれる。 AndroidのLinuxカーネル部分以外のソース Linuxカーネル部分のソース Androidのカーネル部分以外のソース いわゆる、Androidのソースと言われる部分。 いつからか、カーネルが同時に取得できなくなったので、カーネル以外と記載している。 (Armadillo-500fxでは、カーネルも構築する必要があるためである。) Android開発環境構築の手順の中で、ソース取得準備まで実施する ソース取得方法(repo)にあるように、repoコマンドでソースを取得するビルドできるバージョンを使うため、”repo init -u git //android.git.kernel.org/platform/manifest.git -b cupcake"等バージョン指定を実施する その後、"repo sync "を実施する Linuxカーネル部分のソース Linuxカーネルの部分を取得する。 この部分が主にハードウェア用のカスタマイズが必要な部分となる。 また、GPLライセンスに縛られているため、どこかで取得できる。 今回は、Armadillo-500fxが対象となるので、公式から取得する。 ブラウザ等で、Armadillo-500 FXダウンロードを開く Linuxカーネルを取得(確認当時、v2.6.26-at6 でした) ファイル配置 ダウンロードしたソースの配置について記載する。 以降の説明用には、この節で記載したフォルダ構成で記載する。 ”repo init”、"repo sync"を実行したフォルダを「cupcake」とする「cupcake」配下に、「bionic」、「framework」等のフォルダがあることになる ダウンロードしたカーネルファイルを展開する展開すると、「linux-2.6.26-at6」というフォルダができる 展開したフォルダの名称を「kernel」と変更する「kernel」配下に、「drivers」等のフォルダがあることになる 「cupcake」フォルダの中に、「kernel」フォルダを移動する「cupcake/framework/base」、「cupcake/kernel/drivers/usb」等の階層となる 注意事項階層の説明はわかりづらいかも・・。できたら、絵を追加したい。 取得バージョンによっては、例で示すフォルダが存在しない場合がある。 カーネル修正 ダウンロードしたカーネルファイルには、Android用の修正が適用されていない状態である。 その為、Android用の修正を実施するために、修正パッチの適用を実施する。 Android用パッチを取得するブラウザ等で、公式ファイルブラウザ内のandroid directoryを開く 「linux-2.6.26-at-android-tmp-081210.patch」をダウンロードする カーネルにパッチを適用するカーネルフォルダ(cupcake/kernel)内に、ダウンロードしたpatchを移動する 端末で、カーネルフォルダ(cupcake/kernel)内に移動する 端末で、「patch -p1 linux-2.6.26-at-android-tmp-081210.patch」を実施し、パッチを適用する ATDEを使用しない為、Makefileを一部修正する「cupcake/kernel/arch/arm/plat-mxc/sdma/Makefile」をテキストエディタで開く 「KBUILD_CFLAGS = -I$(KBUILD_SRC)/arch/arm/plat-mxc/sdma/iapi/include \」の行を修正する「 =」の部分を「+=」に変更する 注意事項patchの使い方は、うる覚え。試した人は結果ください(汗) Makefileの修正については、以下を参照ください。「Armadillo 04247」 「PATCH」 armadillo-500 make O= building ユーザ空間修正 Armadillo-500fxでのcupcake版ビルドで、ユーザ空間で必要な修正について記載する。 カーネル、Androidバージョンの組合せに依存して発生する。 他の組合せだと不要かもしれない。 Armadillo-500fxで動かす場合のcupcake版での問題点起動時、バッテリ状態が取得できない為、ローバッテリだと判断して、電源OFFしてしまう 対策方法(例:実際できないかも・・)電源管理アプリでダミー値で処理する framework層(java層)でダミー値を返す JNI層(Linuxアプリ層)でダミー値を返す カーネル層でダミー値を返す framework層とJNI層は、ほぼ同等で、java好きか、C++好きかになる。 ここでは、JNI層での修正方法を示す。 対象となるファイルをテキストエディタで開く”cupcake/frameworks/base/services/jni/com_android_server_BatteryService.cpp” バッテリ状態を返す関数の復帰値を変更するgetBatteryStatus()”gConstants.statusUnknown”を常に返すように変更 getBatteryHealth()”gConstants.healthUnknown”を常に返すように変更 readFromFile()bufに文字列”Unknown”(NULL終端付)を入れて、sizeを復帰値とした (bufの領域は、自分できちんと確認してね・・壊れてるかも) setBooleanField()関数readFromFile()をコールし、結果で判断するif処理を削除 変数valueを常にtrueに変更 (要するに、readFromFile()のコールを削除して、value固定化) setIntField()関数readFromFile()をコールし、結果で判断するif処理を削除 変数valueを常に1に変更 (要するに、readFromFile()のコールを削除して、value固定化) 注意事項上記修正は、重複もありそうだけど、良しとした。 JNI層での修正に関しては、EeePc porting - Instructions for last codebaseを参考にして実施。 framework層での修正は、Android 1.5 on Zaurusに修正差分がある。(試してないけど・・) 追加ファイル ビルド時に、”TARGET_PRODUCT=armadillo500fx_dev”等と指定する為、vendor配下に追加するファイルについて記載する。 他の機種(eee_701等)と合わせる為、以下の階層にファイルを作成する ”cupcake/vendor/atmarktechno/armadillo500fx_dev”(これじゃなくても良さそうだけど・・なんとなく・・) 格納するフォルダを作成する上記の”cupcake/vendor/atmarktechno/armadillo500fx_dev” 格納フォルダ内にファイルを作成するAndroid.mkAndroid版Makefileみたいなもの(呼ばれる順番不明)”git clone git //codeaurora.org/platform/vendor/qcom/qsd8250_surf.git”でサンプルを取得 上記取得ファイルの中のAndroid.mkをコピーコメントのみなので、不要である可能性有り AndroidBoard.mkAndroid版Makefileみたいなもの(呼ばれる順番不明)”git clone git //codeaurora.org/platform/vendor/qcom/qsd8250_surf.git”でサンプルを取得 上記取得ファイルの中のAndroidBoad.mkをコピー Armadillo-500 FX用に修正KERNEL_DEFCONFIGに指定するファイルを変更(qsd8650_defconfig→armadillo500fx_dev_android_defconfig) キーボードマップファイルの指定ファイルを変更(surf_keypad.kl→tuttle2.kl) (surf_keypad.kcm→tuttle2.kcm) ブート用のビルド設定を削除”include vendor/qcom/$(TARGET_PRODUCT)/boot/Android.mk”を削除 init.rcのコピー設定を追加”PRODUCT_COPY_FILES +=$(LOCAL_PATH)/init.rc root/init.rc”を追加 (正しいか不明) AndroidProducts.mkAndroid版Makefileみたいなもの(呼ばれる順番不明)”git clone git //codeaurora.org/platform/vendor/qcom/qsd8250_surf.git”でサンプルを取得 上記取得ファイルの中のAndroidProducts.mkをコピー Armadillo-500 FX用に修正(qsd8250_surf.mk→armadillo500fx_dev.mk) armadillo500fx_dev.mkAndroid版Makefileみたいなもの(呼ばれる順番不明)”git clone git //android.git.kernel.org/platform/vendor/htc/dream-open.git”でサンプルを取得 上記取得ファイルの中のhtc_dream.mkをコピー ファイル名を”armadillo500fx_dev.mk”へ変更 Armadillo-500 FX用に修正変数”PRODUCT_NAME”を変更(htc_dream→armadillo500fx_dev) 変数”PRODUCT_DEVICE”を変更(dream-open→armadillo500fx_dev) 変数”PRODUCT_MANUFACTURER”の記載を削除 BoardConfig.mkAndroid版Makefileみたいなもの(呼ばれる順番不明) デバイスに合わせてフラグ設定をまとめている?”git clone git //codeaurora.org/platform/vendor/qcom/qsd8250_surf.git”でサンプルを取得 上記取得ファイルの中のBoardConfig.mkを参考に作成するデバイス依存部の削除とブート関連記載の削除 (基本、genericで、カーネルビルドだけ付加した形かな) 以下がArmadillo-500 FX用の設定TARGET_NO_BOOTLOADER = true TARGET_NO_KERNEL = false(カーネルビルド用) TARGET_NO_RADIOIMAGE = true BOARD_USES_GENERIC_AUDIO = true USE_CAMERA_STUB = true TARGET_BOOTIMAGE_USE_EXT2 = true(たぶん、不要) TARGET_USERIMAGES_USE_EXT2 = true(たぶん、不要) init.rc起動時に、initから参照される設定ファイル initでのコマンド解釈ルールにより、動作する 必須ではない為、”.mk”内にコピー用の記載が必要。 デフォルトだと、"cupcake/system/core/rootdir"内のファイルになる?(要確認)同名ファイルが他に存在? (要確認)環境変数”TARGET_PROVIDES_INIT_RC”が影響?デフォルトファイルから、”yaffs2”の記載がある行を”#”でコメントアウトマウント設定、権限設定があるので、見直しの必要有り system.prop設定ファイル(よくわかっていない) 予想:特定用途のライブラリ、インタフェイスの設定"cupcake/build/target/board/generic"内からコピー tuttle2.kcmキーボードマップ関連(よくわかっていない)"cupcake/build/target/board/generic"内からコピー tuttle2.klキーボードマップ関連(よくわかっていない)"cupcake/build/target/board/generic"内からコピー カーネルをビルドする為に、"cupcake/kernel"配下にファイルを追加するAndroidKernel.mk”git clone git //codeaurora.org/kernel/msm.git”でサンプルを取得カーネル一式なので、重たいかも・・ AndroidKernel.mkをcupcake/kernel内にコピー サンプル2と3のサンプルを添付ファイルとしてアップ(armadillo_cust.tar.gz) ライセンスとか問題あったら、指摘してください 注意事項”.mk”の記載ルールがはっきりとわかっていない為、間違ってるかも 現状、不明なファイルについては、generic時に使用されるファイルを使用 当初、書込みファイル自体不明だった為、不要な設定も含まれているかも パス設定 Armadillo-500FXは、CPUがARMとなっている。 一方で、ビルドマシンとしては、x86を想定している。 上記のため、クロスコンパイラ用のパスを追加する必要がある。 その為のパス設定について記載する。 クロスコンパイラの場所cupcake/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/ cupcake/prebuilt/linux-x86/toolchain/arm-eabi-4.3.1/bin/ cupcake/prebuilt/linux-x86/toolchain/i686-unknown-linux-gnu-4.2.1/bin/ パス設定の追加"cupcake/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/”へのシンボリックリンクを作成する(以下、arm-eabi-4.2.1を作成したリンクとする)端末で、"ln -s"コマンドを使う 上記手順は不要な場合がある 端末上で、"PATH=$PATH arm-eabi-4.2.1"として、PATHへ追加する毎回書くのはめんどくさいので、.bashrc とか、ビルドスクリプトに入れると良い ビルド方法 ビルド方法を記載する。 端末で、”cupcake”フォルダまで、移動する "export TARGET_PRODUCT=armadillo500fx_dev"とコマンドを入力する "make"とコマンドを入力する ビルドスクリプト ビルドの為のスクリプトを紹介しておく ビルドの為の設定が面倒くさい為に作成した。 ”build_dev.sh”を作成名前はなんでも良い (あくまで、参考程度・・)パス設定を記載 環境設定を記載(例:"export TARGET_PRODUCT=armadillo500fx_dev") ビルドコマンドを記載(”make”等) 上記ファイルを作成すると、ビルドは以下の手順で良い 端末で、"cupcake"フォルダに移動する ". build_dev.sh"とコマンドを入力する ビルド生成物 上記ビルド構築環境でのビルド生成物について記載する ビルド生成物作成フォルダcupcake/out/target/product/armadillo500fx_dev Armadillo書込み対応ファイル/フォルダカーネルcupcake/out/target/product/armadillo500fx_dev/kernel(以降、$KERNEL) ユーザランドcupcake/out/target/product/armadillo500fx_dev/root(以降、$ROOT) cupcake/out/target/product/armadillo500fx_dev/system(以降、$SYSTEM) Armadillo-500 FXへの書込み$KERNELをhermit等でカーネル領域に書き込む ROMのユーザ領域には、Armadillo開発者サイトにあるAtmark Distユーザランドを書き込む Androidユーザ層を構築するローカルに"android"フォルダを作成する $ROOTのフォルダ/ファイルを”android”内にコピー $SYSTEMのフォルダ/ファイルを”android/system”内にコピー 構築したユーザ層をArmadillo-500 FXの/dev/sda1に書き込む/dev/sda1への書込みは、Armadillo開発者サイトを参照してください 注意事項構築するアプリ等に依存して、別途dataフォルダの考慮が必要になる 未解決問題 未解決な問題について記載する ビルド生成物の操作方法 ”chroot”を使わないArmadillo-500FXのAndroid起動方法 各種、環境変数の影響 キーマップファイルの効果 .mkファイル内のAndroid特有コマンド 何かあれば、書き込みます・・。 検証中 未解決問題の中で、今、検証中のものを記載する。 途中経過も書いていければいいな。 現状、検証中はありません。
https://w.atwiki.jp/visufuri/pages/422.html
525 名前:Nana[sage] 投稿日:2007/07/06(金) 20 38 07 ID gaCqxA4IO セクアンのフリの基本系は見ればすぐ覚えられる程度でしょうか? 地方住みでめったにライブに行けないので記憶になくて… 今夏には参戦する予定なので基本ぐらいは覚えて行きたいのですが 528 名前:Nana[sage] 投稿日:2007/07/06(金) 21 54 34 ID 4GRgViMo0 525 曲によっては1回見ただけじゃちょっと難しい曲もある。 曲中に咲くフリがあったりジャンプしたりがほとんどだから するタイミングさえ分かってれば大丈夫だよ。 ちなみに咲きフリ(?)があるのは 狂い咲き~・キャバレー・タメライ~・九十九里~・発狂・システマぐらいかな。 あとはジャンプしたり逆ダイしたりヘドバンしたりお好きに楽しんで下さいw 多分同じイベント参加だと思うのでwお互い楽しみましょう(´∀`) 535 名前:Nana[sage] 投稿日:2007/07/08(日) 02 48 41 ID RpwDiE7hO 528 ご丁寧にありがとうございます! イベント楽しみたいと思います!笑 逆ダイ等は曲の感じや周りを見れば分かりそうなのですが, どの時に咲くか教えていただく事ってできますか? 余りに多いようでしたら結構ですので,すみません。 538 名前:Nana[sage] 投稿日:2007/07/08(日) 19 42 51 ID uLZ00z1m0 535 狂い咲き→狂い咲きの咲きの部分で咲いてバーニングラブのラブの部分で 右手の人差し指と親指でLを作る(手のひらが自分側にくるように) ↑のLは東京crazy loveのラブでもやります。 タメライ傷~→胸が裂けますか?といつか咲けますか?で咲く。 あなたがいないのはで好きな麺を指してw 嫌…で人差し指を振り子みたいに左右に揺らす。 九十九里~→愛しすぎて~の「愛し」でハートの片方、「すぎ」でもう片方 「て」で作ったハートを前に出す×2 「狂い」でハートを一回転させて 「咲く」で咲く。あとの恋花火の部分も同じ。九十九里浜~の部分は ステージに向けて指を交互にさしてロマネスクで咲く。 キャバレー→最初っからモッシュ(ジャンプ)の嵐wサビでもジャンプ。 キャバレーで咲く。 発狂ロリポップ→ロリポップで咲く BABY~とCHERRY~で作ったハートを 前に出すフリがあるけどあんまり浸透してない感じ。 システマ→サビは手扇子。クロガネの花は咲くで咲く 人間休業と哀川翔ではひたすらヘドバンと逆ダイw もっとそれぞれ細かくはありますが基本はこんな感じです。 説明下手で長い上によくわからなかったらスミマセンorz 955 名前:Nana[sage] 投稿日:2007/08/21(火) 12 46 09 ID IZhLJwcTO どなたかSEX-ANDROIDの『夏色サディスティック』のサビのフリ教えてください。 よろしくお願いします。 967 名前:Nana[sage] 投稿日:2007/08/22(水) 01 52 16 ID SdQPsVn5O 夏色とタメライ傷と発狂は常連フリだから常連に聞くしかないよ
https://w.atwiki.jp/android/pages/44.html
アンドロイドアプリケーション設計思想 たとえプラットホーム自体がひどく異なるとしても、新しいAPIのためにアプリケーションを造る方法を学ぶプロセスはかなり類似しています。 Generally, there are two phases first, you learn how to use the APIs to do what you want to do; later, you learn the nuances of the platform. Put another way, first you learn how you can build applications; later, you learn how you should build them. 通常、2つの段階があります: 最初にしたいことをするためにAPIを使用する方法を学びます; 次にプラットホームの差分を学びます。 これとは異なる方法として 最初にどのようにアプリケーションを構築することができるかについて学びます 次にどのようにそれらを造らなければならないかについて学びます That second phase — learning the right way to build applications — can often take a long time, and frequently means "paying your dues", making mistakes, and learning from them. Well, that's not a very efficient process, so this page and the links below aim to give you a helping hand. その第二段階 — アプリケーションを構築する正しい方法を学ぶこと — 長い間「あなたの会費を払ったうえで間違った方法を学んでいることはよくあります。 れはあまり効率的なプロセスでないので、このページと下のリンクはあなたに援助の手をしようとします。 Before we dive into it, a quick word. Successful applications will offer an outstanding end-user experience. While the Android team has built a robust core system, the vast majority of the user experience will come from users interacting with your applications. As a result, we encourage you to take the time to build an outstanding user experience. An outstanding user experience has three key characteristics it is fast; it is responsive; and it is seamless. Of course every platform since the dawn of computing has probably cited those same three qualities at one time or another. However, each platform achieves them in different ways; the information below explains how your apps can achieve them on Android. 顕著なユーザー経験には、 3つの鍵となる特徴があります: 速い レスポンスに優れる; シームレスに動きます。 もちろん、かつてコンピューティングの始まりからあらゆるプラットホームは、その3つの特性をおそらく掲げているだろうが、各々のプラットホームは、それら異なる方向において成し遂げます; 下記の情報は、アプリがどのようにAndroidの上でそれらをできるかについて説明します。 Fast An Android application should be fast. Well, it's probably more accurate to say that it should be efficient. There is a tendency in the computing world these days to assume that Moore's Law will solve all our problems — eventually. When it comes to embedded applications, though, Moore's Law is a bit more complicated. Androidアプリケーションは速くなければなりません。速くするには効率的でなければならないと言うことは明白です。 ムーアの法則がこれらの問題を解決すると仮定するとして、近頃のコンピューティングの傾向である。 組込形アプリケーションに関しては、ムーアの法則はもっと複雑である Moore's Law doesn't really apply to mobile devices in the same way as to desktop and server applications. Moore's Law is actually a law about transistor density — that is, it says that you can pack more circuitry into a given chip size, over time. ムーアの法則は、デスクトップとサーバーアプリケーションにと同様にモバイル機器に本当にあてはまりません。 ムーアの法則は、実はトランジスタ集積についての法則です それは、時間とともにより多くの回路を決められたチップサイズに集積することができると言うことです。 For desktop and server applications, this means you can pack more "speed" into a chip of roughly the same size, resulting in the well-known performance increases. For embedded applications like cell phones, however, Moore's Law is usually exploited to make chips smaller. That is, the tendency is to use the increased density to make the same chip smaller and consume less power, to make phones smaller and make batteries last longer. デスクトップアプリとサーバーアプリのために、同じサイズのチップでも速度をに集積することができることを意味します。 知ってのとおりパフォーマンス増加に終わります。 しかし、携帯電話のような組込形アプリケーションのでは、ムーアの法則は通常チップをより小さくするために利用されます。 つまり、傾向は同じチップをより小さくして、より少ない力を消費するために増加した密度を使うことです。 電話をさらに小さくして、バッテリーを長く持続させます。 As a result, embedded devices like phones are increasing in actual, raw speed much more slowly than desktop systems. For embedded devices, Moore's Law means more features and better battery life; increased speed is only an afterthought. その結果、電話のような組込形デバイスはデスクトップシステムより非常に遅く、実際の実行速度が増える。 組込形デバイスで言うムーアの法則はより多くの特徴と、より良いバッテリーの寿命を意味します; 増強された速度は結果論であるにすぎません。 That's why it's important to write efficient code you can't assume that phones will see the same speed increases as desktops and servers. Generally speaking, writing fast code means keeping memory allocations to a minimum, writing tight code, and avoiding certain language and programming idioms that can subtly cripple performance. In object-oriented terms, most of this work takes place at the method level, on the order of actual lines of code, loops, and so on. The article on Writing Efficient Android Code will give you all the detail you need to write fast, efficient code for Android. Responsive It's possible to write code that wins every performance test in the world, but that still sends users in a fiery rage when they try to use it. These are the applications that aren't responsive enough — the ones that feel sluggish, hang or freeze for significant periods, or take too long to process input. In Android terms, applications that are insufficiently responsive will frequently cause the system to pop up the dreaded "Application Not Responding" (ANR) message. Generally, this happens if your application cannot respond to user input. For example, if your application blocks on some I/O operation (frequently a network access), then the main application thread won't be able to process incoming user input events. After a time the system will conclude that your application has hung, and give the user the option to kill it. Similarly, if your application spends too much time building an elaborate in-memory structure, or perhaps computing the next move in a game, then again the system will conclude that your application has hung. It's always important to make sure these computations are efficient using the techniques above, but even the most efficient code still takes time to run. In both of these cases, the fix is usually to create a child thread, and do most of your work there. This keeps the main thread (which drives the user interface event loop) running, and prevents the system from concluding your code has frozen. Since such threading usually is accomplished at the class level, you can think of responsiveness as a class problem. (Compare this with basic performance, which was described above as a method-level concern.) The article on Building Responsive Android Applications discusses responsiveness in detail. Seamless Even if your application is fast and responsive, it can still annoy users. A common example is a background process (such as an Android Service or IntentReceiver) that pops up a UI in response to some event. This may seem harmless, and frequently developers assume that this is okay because they spend most of their time testing and using their own application. However, Android's application model is constructed explicitly to allow users to fluidly switch between applications. This means that when your background process actually fires up that UI, the user could be way over in another part of the system, doing something else — such as taking a phone call. Imagine if the SMS service popped up a dialog box every time a text message came in; this would annoy users in no time. That's why the Android standard is to use Notifications for such events; this leaves the user in control. That's just one example; there are many more. For example, if Activities don't correctly implement the onPause() and other lifecycle methods, this will frequently result in data loss. Or, if your application exposes data intended to be used by other applications, you should expose it via a ContentProvider, rather than (for example) using a world-readable raw file or database. What those examples have in common is that they involve cooperating nicely with the system and other applications. The Android system is designed to treat applications as a sort of federation of loosely-coupled components, rather than chunks of black-box code. This allows you as the developer to view the entire system as just an even-larger federation of these components. This benefits you by allowing you to integrate cleanly and seamlessly with other applications, and so you should design your own code to return the favor. This is a component-level concept (as opposed to the class- and method-level concepts of performance and responsiveness, described above.) The article on Integrating with the System provides tips and best practices for writing code that cooperates nicely with the rest of the system.
https://w.atwiki.jp/android/pages/51.html
なるべく集めて回るけど作ったひとが自発的に追加してくれるとありがたいなあ - kojira 2008-02-12 21 54 53 プラグイン追加とかが自分で出来ないから不便だなあ。そのうち移転するかも。 - kojira 2008-02-18 23 09 07
https://w.atwiki.jp/api_programming/pages/205.html
下位ページ Content 同じプロジェクト内のアクティビティにインテントを投げる ブラウザでURLを開く インテントとインテントフィルター | Android Developers 同じプロジェクト内のアクティビティにインテントを投げる Intent オブジェクトを生成する際に、先のアクティビティを指定しておく Intent intent = new Intent(ThisActivity.this, TargetActivity.class); // 指定しておく intent.putExtra("info", dataInfo); // インテントに投げる情報を載せる startActivity(intent); // インテントを投げる ブラウザでURLを開く URI をセットしたインテントを投げる。 Uri uri = Uri.parse(“http //www.google.com/”); Intent i = new Intent(Intent.ACTION_VIEW,uri); startActivity(i);
https://w.atwiki.jp/memodroid/pages/19.html
・docomo初のAndroid搭載スマートフォン ・ベースはHTC Magic ・初期化方法 1.最初に端末の電源を落とす。 2.端末を起動する際に、「ホームキー」と「電源キー」を同時押ししながら起動する。 3.docomoのロゴが表示された際に、「ホームキー」と「電源キー」を同時押しする。 4.「wipe data/factory reset」 5.「reboot」 引用 LV11:HT-03A初期化方法(システムリカバリーユーティリティを使用した場合) docomo PRO series HT-03A _ 製品 _ NTTドコモ
https://w.atwiki.jp/esperna/pages/15.html
eclipseにopencvをimport後、buildするのに苦戦したがcleanしてからBuildしたらあっさり解決 Nexus7をUSBでPCにつないで、動かなかったがケーブル変えたら動いた。 動かなかったケーブルも充電はできていたので、充電はできるけどそもそも認識されないUSBケーブルもあるということか?? 参考リンク AndroidでOpenCVを使ってみよう OpenCV for Android 2.4.3.2 のインストール OpenCV for Android 2.3.1 beta2 のインストール手順 OpenCVで単純な画像処理(ネガポジ反転)
https://w.atwiki.jp/objcmemo/pages/18.html
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ スクロール(矩形指定) _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ [aView scrollRectToVisible (CGRect) animated (BOOL)]; 矩形が見える位置までスクロールする。その際、追跡プロパティとドラッグプロパティはどちらもNOになる。 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ステータスバーによる最上部にスクロール制御 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ステータスバーをタップしたときに一番上までスクロールする機能。 この動作もUIScrollViewの処理で、デリゲートメソッドをオーバーライドすることによって、この機能をオフにすることもできる。 例えばこれを利用することで、画面内に複数のScrollViewがある場合に、ステータスバータップ時にどのScrollViewをスクロールさせるかを制御することが可能となる。 (BOOL)scrollViewShouldScrollToTop (UIScrollView *)scrollView; また、この動作によってアニメーションが完了したときに以下のデリゲートメソッドが呼ばれる。 (void)scrollViewDidScrollToTop (UIScrollView *)scrollView; _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 最上部にスクロール _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ [scrollView setContentOffset CGPointMake(0, 0) animated YES]; _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 最下部へのスクロール _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ if (scrollView.contentSize.height scrollView.bounds.size.height) { CGPoint bottomOffset = CGPointMake(0, scrollView.contentSize.height - scrollView.bounds.size.height); [scrollView setContentOffset bottomOffset animated YES]; } _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ スクロールバー消去 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ scrollView.showsVerticalScrollIndicator = NO; scrollView. showsHorizontalScrollIndicator = NO; _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ スクロール _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ // CGPointの位置が左上角になるようにスクロールする [scrollView setContentOffset CGPointMake(50, 50) animated YES]; // 以下はどちらも意味は同じ、アニメーションなしでスクロール [scrollView setContentOffset CGPoint(50, 50) animated NO]; scrollView.contentOffset = CGPoint(50, 50); // トップにスクロールする [scrollView setContentOffset CGPointMake(0.0f, 0.0f)]; [scrollView setContentOffset CGPointMake(0.0f, 0.0f) animated YES]; _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ プロパティ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ・contentSize ScrollViewが内包するコンテンツのサイズ。スクロール領域。 ・contentInset 余白。contentSizeにcontentInsetを足したものが最終的なScrollViewのサイズになる。 ・scrollIndicatorInsets スクロール時に表示されるインジケータのinset。contentInsetを設定したらこちらも設定しないとスクロールバーが変なところに表示されるので注意すること。 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ デリゲート _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ /** * ドラッグ(スクロール)開始時に呼ばれる。 * @param scrollView 対象UIScrollView * @return 無し */ - (void)scrollViewWillBeginDragging (UIScrollView *)scrollView { NSLog(@"scrollViewWillBeginDragging"); } /** * スクロールしている間に呼び出される。 * @param scrollView 対象UIScrollView * @return 無し */ - (void)scrollViewDidScroll (UIScrollView *)scrollView { NSLog(@"scrollViewDidScroll"); [self updateSelectedItem]; } /** * ドラッグ後、慣性が効いて動いたあとに止まった場合に呼ばれる。(慣性なしでドラッグを終えた場合は呼ばれない) * @param scrollView 対象UIScrollView * @return 無し */ - (void)scrollViewDidEndDecelerating (UIScrollView *)scrollView { NSLog(@"scrollViewDidEndDecelerating"); [self updateSelectedItem]; } /** * ドラッグ後、指がデバイスが離れた時に呼ばれる。慣性が効いて動く場合はdecelerateがYESになる * @param scrollView 対象UIScrollView * @return 無し */ - (void)scrollViewDidEndDragging (UIScrollView *)scrollView willDecelerate (BOOL)decelerate { } /** * アニメーション完了後に呼び出される。(setContentOffset animated メソッドのanimatedがNOの場合は呼び出されません。 * @param scrollView 対象UIScrollView * @return 無し */ - (void)scrollViewDidEndScrollingAnimation (UIScrollView *)scrollView { NSLog(@"scrollViewDidEndScrollingAnimation"); } /** * 選択状態の項目を更新する。 * @param 無し * @return 無し */ - (void)updateSelectedItem { NSArray *array = [tabListView indexPathsForSelectedItems]; if ([array count] == 1) { NSIndexPath *indexPath = array[0]; [tabListView selectItemAtIndexPath indexPath animated NO scrollPosition UICollectionViewScrollPositionNone]; } } _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ 一瞬だけスクロールバーを表示する _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ [scrollView flashScrollIndicators];
https://w.atwiki.jp/westj/pages/14.html
ここを編集